I've reviewed dozens of development engagements over my years as a fractional CTO, including many that went badly. Almost every expensive failure had the same root cause: the founder hired someone without asking the right questions first.
The problem is that bad development companies are very good at sounding good. Their websites are polished. Their discovery calls are smooth. Their proposals arrive quickly with confident pricing. And none of that tells you anything meaningful about whether they will actually deliver.
These are the questions that separate the ones worth hiring from the ones you should walk away from.
Questions About Their Track Record
1. Can I speak directly with three past clients you've worked with in the last 12 months?
This is the most important question you can ask. Any company with a genuine track record will say yes immediately. Companies that hedge, offer testimonials instead, or suggest you contact only carefully selected references should be treated with serious skepticism.
When you actually speak to those clients, ask specifically: Did the project come in on time? On budget? What went wrong and how did the team handle it?
2. Can you show me a live product you built from scratch that has real users?
Portfolio items on websites are curated. Ask to see something live, with real users, that you can use yourself. The gap between "we built this" and "this product works in the real world" is enormous.
3. Have you built AI-powered products before? What were the specific challenges?
If you're building an AI product, you need a team with direct experience. AI development has specific complexities around prompting, latency, cost management, and unpredictable behavior that a team without AI experience will encounter for the first time on your project.
4. What happened on a project that didn't go well? How did you handle it?
Every team that has done enough work has had a project that went poorly. Teams that claim otherwise either haven't done much or aren't being honest. The way a team handles failure tells you more about their professionalism than their success stories do.
Questions About Their Process
5. What does your discovery phase look like?
Any development company worth hiring has a structured process for understanding what to build before they build it. If they skip straight to quoting you, they are skipping the most important step.
6. How do you handle scope changes?
Scope changes happen on every project. Ask specifically: What's the process? How are they documented? How does it affect timeline and cost? A clear, fair answer here shows maturity. Vague answers suggest future disputes.
7. How do you communicate progress? What does a typical week look like for the client?
You want to know how often you'll hear from them, what format updates take, and how quickly they respond when you have a question. "We'll send weekly status reports" is very different from "you'll have a shared project board and a 30-minute sync every week."
8. Who specifically will be working on my project?
Many companies win projects with senior people in the sales process, then hand the work to junior developers. Ask to meet the actual team who will build your product before signing. If they can't tell you specifically, that's a red flag.
9. What percentage of your work is outsourced to third parties?
Some agencies subcontract significant portions of the work. This isn't automatically bad, but you should know about it. Subcontracting without disclosure creates accountability gaps that become your problem.
Questions About Technical Approach
10. What technology stack would you recommend for this product, and why?
Their recommendation matters less than their reasoning. A good team will explain the tradeoffs, acknowledge alternatives, and tailor the recommendation to your specific needs. A team that recommends the same stack for everything regardless of context is not thinking carefully about your product.
11. How do you approach technical debt, and what's your code quality process?
Fast development and clean code are often in tension. Ask how they balance the two. Do they do code reviews? Do they write tests? A team that talks exclusively about speed without mentioning quality is likely to deliver something that works on day one but becomes expensive to maintain.
12. What does the handover look like at the end of the engagement?
If you need to work with other developers in the future, or bring engineering in-house, the quality of the handover matters enormously. Ask specifically about documentation, code comments, architecture diagrams, and deployment runbooks.
Questions About Timeline and Cost
13. How did you arrive at this estimate?
Ask them to walk you through the estimate. Breaking down cost by feature or phase shows real planning. A number that appeared with little explanation is a guess dressed as a quote.
14. What are the most likely causes of timeline slippage on this type of project?
A team that can answer this fluently has seen these projects before and knows where the problems come from. A team that says "we always deliver on time" has either done very few projects or is not being honest.
15. What is not included in this quote?
This is the question that uncovers surprise costs. Third-party services, API costs, design beyond wireframes, QA testing, deployment infrastructure, post-launch support: all of these are commonly excluded from initial quotes. Get clarity before signing.
Questions That Reveal Culture and Fit
16. When you think our approach is wrong, what do you do?
You want a team that will tell you when you are making a mistake, not just execute whatever you ask for. A studio that describes specific times they've pushed back on a client's idea and how they handled that conversation is showing you that they take the product outcome seriously.
FeatherFlow is a good example of a studio where this kind of challenge is built into the process, not an uncomfortable exception to it.
17. Who owns the code and IP at the end of the engagement?
This should always be you. If a development company cannot confirm unambiguously that you own all the code and intellectual property they produce for you, do not sign anything.
18. What are your payment terms, and what are the conditions under which either side can end the engagement?
Clear terms protect both parties. Vague terms benefit whoever has more leverage when things go wrong, which is usually not you.
19. What would make this project a success for you?
This question reveals how they think about their work. Teams focused purely on delivery will talk about timeline and budget. Teams that genuinely care about product outcomes will talk about what happens after launch.
20. What do you need from me to be successful?
The best development partners will have a clear answer: timely feedback, decisions made within a certain timeframe, access to relevant stakeholders. Teams that have no requirements of you are usually teams that will proceed without the input they actually need, then surprise you with results that don't match your expectations.
What to Do With the Answers
You are not looking for perfection. You are looking for honesty, competence, and evidence of having done this before.
Red flags to walk away from: inability to provide direct client references, vague or defensive answers about what went wrong in the past, no clear process for scope changes, unclear ownership of deliverables.
Positive signals to pay attention to: specific answers with real examples, clear processes with documented steps, willingness to push back on your ideas, and genuine curiosity about your product problem.
Frequently Asked Questions
How long should the vetting process for a development company take?
Plan for at least two to three weeks of serious evaluation if you're making a significant investment. This includes an initial call, a discovery session, reference checks, proposal review, and follow-up questions. Rushing this process because you're excited about starting is one of the most common mistakes founders make.
Is it normal to pay for a discovery phase before committing to a full build?
Yes, and it's actually a good sign. A development company that offers a paid discovery phase is demonstrating that they value the strategy and scoping work enough to charge for it properly, rather than rushing to get to the build contract. A free discovery phase typically means the scoping is superficial.
Should I get multiple quotes?
Yes. Getting two or three quotes helps you calibrate whether pricing is reasonable and gives you comparison points for the questions above. Be wary of the lowest quote: it usually reflects scope that is missing something, a team that is less experienced, or an estimate that will expand significantly once the project starts.
What if a company doesn't want to answer these questions?
Walk away. Professional teams welcome due diligence. Companies that get defensive or dismissive when asked straightforward questions about their process and track record are telling you something important.
Do these questions apply to product studios as well as agencies?
Yes, and they're even more important for product studios, since you're typically paying more and expecting more from the relationship. The answers should be more substantive from a studio than from a pure execution agency, since studios claim to bring product thinking to the table.